Fetch cheaply: a worker learns what a fetch costs, and a dispatch says what it is doing - #443

Summary

Two things agents were left to work out for themselves. What a fetch costs — so a worker fetched the
same technique twice inside 46 seconds, and probed resource ids under alternate spellings when the
right one was in the response it was holding. And what a dispatch is doing — so one ran fifteen
minutes with nothing for the user to read, and the checkpoint it was heading for arrived unannounced
while they sat waiting on it.

Work item W3, the corpus half of W8, and the running-dispatch signal that extends W2, all of the
delivery-cost epic #404. Stacked on #439.

Fetch guidance

Four things a worker now reads, all of them in workflow-engine's container rules where the fetch
contract already lives:

• Ids come from the delivery. The resources map keys, resource_refs, and the refs in the
  operation bodies the response carried, each already qualified. A ref that will not resolve is a
  definition defect to report — not a spelling to search for. An id guessed under another workflow
  prefix costs a round trip and returns an error, and the one that would have worked was in the
  response.
• A fetch hands over the whole composed body. With the measured range from one real run: lazy
  technique fetches ran 5,242 to 15,126 characters apiece, lazy resource fetches 1,426 to 14,980.
• A repeat under the same agent_id comes back as a marker, because the ledger records that this
  context received those bytes. So a repeat costs the round trip rather than the body, and the marker
  is the expected answer rather than an error. This is behaviour Send once: a delivery stops repeating what it has already handed over, and says where the context stands #441 adds; the guidance describes it
  rather than promising it.
• A shared block inside one activity response may be a marker whose bytes an earlier
  step_techniques entry of that same response carries in full — read it from there. Also Send once: a delivery stops repeating what it has already handed over, and says where the context stands #441.

progressive-step-technique-load now says plainly that an inlined step is read from the bundle,
because re-fetching it pays the round trip for content the response already delivered.

Where the batch standing is read

#441 puts the standing in the response text as a leading batch: block, because _meta was not where
a worker reliably read it — on the 5 August run no context anywhere took a second activity and nothing
was refused either, because no continuation was ever attempted. The three places in the corpus that
name the field now name the block: the worker's verify-dispatch phase, the rule that governs where a
batch ends, and finalize-activity's input that carries the answer into the envelope.

A dispatch says what it is doing while it runs

The orchestrator announces each dispatch before it spawns: what is running, the gate the user's answer
is next needed at, and the elapsed figure of the last comparable dispatch where the session record has
one. The rule behind it carries what the phase cannot: no minute of a run is silent, so the waits the
orchestrator itself imposes between dispatches — a commit cycle, a reconciliation, a retry — are named
as they happen, and where a dispatch is one of a run of activities under one worker, which of the run
it is belongs in the announcement.

W2 puts the same measurement on the log, facing the operator. This is the half that faces the person
waiting.

Scope of change

Five definition files, all in the meta workflow: workflow-engine/TECHNIQUE.md (one rule extended,
one added), activity-worker.md, finalize-activity.md, dispatch-activity.md (one protocol phase,
one rule), and the workflow version. No activity YAML, no schema, no server change.

Verification

All 24 guards pass against this corpus.

Dependencies

The fetch guidance and the batch-standing location describe server behaviour that lands with #440 and
#441. Merging this first would document behaviour the server does not have yet.

Non-goals

• Where a lazy fetch's cost comes from. The resolve work behind it is Resolve once: a delivery reads each technique one time, and says what it cost #440's, and this guidance quotes
  what a fetch delivers rather than how the server builds it.
• The eager bundle's budget behaviour, unchanged.
• Retiring any fetch. The point is that a worker asks for what a step needs and reuses what it already
  has, not that it asks less.

Investigation detail

engineering/artifacts/planning/2026-08-06-startup-cost-on-real-runs
— the repeat-fetch tables and the per-delivery figures quoted above.